home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Floppyshop 2
/
Floppyshop - 2.zip
/
Floppyshop - 2.iso
/
diskmags
/
0022-3.564
/
dmg-0079
/
763.txt
< prev
next >
Wrap
Text File
|
1997-04-16
|
16KB
|
368 lines
INFO-ATARI16 Digest Wed, 6 Dec 89 Volume 89 : Issue 763
Today's Topics:
C question
Form Doc's
Spectre & Adobe Type Manager
SS -> DS drive upgrade
STOS Basic
What does the read-only bit mean?
What Kermit/UNITERM bugs? (2 msgs)
----------------------------------------------------------------------
Date: 6 Dec 89 20:12:57 GMT
From: cscnj!pat@rutgers.edu (Patrick Hester)
Subject: C question
Message-ID: <564@cscnj.csc.COM>
In article <875@lzaz.ATT.COM>, hcj@lzaz.ATT.COM (HC Johnson) writes:
+ In article <8912050802.AA12717@ucbvax.Berkeley.EDU>,
S61304@PRIME-A.POLY-SOUTH-WEST.AC.UK (Rat) writes:
+ >
+ > Why wont Sozobon, Lattice or any other C compiler I've tried compile the
+ > following, from K&R?
+ >
+ > main()
+ > $
+ > char fred[] = "Some string constant";
+ > <rest of routine>
+ >
+ >
+ > This has been confusing me for a while, as K&R (surely correct!) would
+ > seem to indicate that this is indeed permissible!
+
+ NO NO NO
+
+ you can have char *fred[] = "hello";
+ or
+ char fred[] = ?'h','e','l','l','o','\0'?;
+
+ but not
+ char fred[] = "hello";
yes you can.
it sets up an array of chars including a null.
fred then refers to the address of the first byte in the array
and fred[n] is one char.
you usually can't do this, tho, inside a function unless you
declare it static. Also, it's gotta be before any program instructions
on most compilers.
--
"We've all been used 8=8 made loud to play loud
and reused..." --<-@
"And abused." =8(/\/) rutgers!cscnj!pat
"And amused!" 8=======8 (201)-562-6533
------------------------------
Date: 6 Dec 89 03:46:06 GMT
From: davidli@UMN-CS.CS.UMN.EDU (David Paschall-Zimbel)
Subject: Form Doc's
Message-ID: <17468@umn-cs.CS.UMN.EDU>
In article <473eecf4.14a1f@force.UUCP> covertr@force.UUCP (Richard E. Covert)
writes:
>Hey, it doesn't seem like many folks like the TeX docs to form.
Might be because they didn't have any idea what to do with the .DVI file.
Of course, if you're receiving comp.sys.atari.st, then it's fairly likely
that you have access to a .DVI driver AND a laser printer, like I did.
The docs are quite beautiful when printed on a laser printer. So, at
least ONE person liked the documentation.
>Must be some form of Elitest mentatlity to post docs to a program
>in a format that 99% of the people don't use.
Must be some form of Elitist mentality to DEMAND documentation to a program
be put up in a manner convenient to _them_. The program didn't _HAVE_ to
be posted in the first place. Would you have been happier if that was
the case? If not, I'd suggest you take your 'Elitist' mentality and go
somewhere else.
>Hey, if you are good enough you will have TeX, right? :-)
For the information of All Concerned. You do not need the entire TeX
release to process a .DVI file. You need a .DVI driver (at our humble
little site I have access to a DVItoPostScript and a DVItoLN03 driver),
the requisite fonts and a printer. Heck, you could even use the
DVItoEpson driver that's available via ftp.
Most everyone who has access to network news has access to TeX, if they
really wanted to take the time to find out...
-- David Paschall-Zimbel
------------------------------
Date: 6 Dec 89 20:17:19 GMT
From: brunix!iris.brown.edu!mjv@uunet.uu.net (Marshall Vale)
Subject: Spectre & Adobe Type Manager
Message-ID: <22321@brunix.UUCP>
We just received Adobe Type Manager and of course I quickly installed it
on my Spectre GCR system to see if it worked. First, a little background.
Adobe Type Manager replaces the way the Mac displays fonts on screen.
Noramlly, the Mac uses bitmaps that are installed into the system. To get
a nice looking font on the screen, you need to have that particular size
installed for it to look nice. If you don't, then the Mac's QuickDraw
routines will try to scale it and most often, it looks very, very ugly.
ATM catches all those font scallings and uses its own outline fonts to
create nice, clean fonts in any size. This is very important for both
the screen and ImageWriter (or other dot matrix and QuickDraw printers)
in that all the fonts will scale smoothly.
My system is a Mega2 with a ICD host adapter and Seagate 277R 65 meg HD
and the Spectre GCR. The ATM disk contains the ATM INIT (an auto file)
and a control panel document (Cdev). There are two inits, one for the
68000 Macs and one for the 020/030 Macs; we, of course, use the 68000 one.
The disk also contains the outline font files for 4 fonts and their
bitmap fonts. For the ATM to work, you also need at least one bitmap size
font installed, the more the better(10 and 12 is a good minimum). You can
turn ATM on or off from the control panel and boot up in case an
application will not work with it.
Here are some interesting figures I found after using ATM for a bit.
Installing ATM and all the outline fonts files for the all the fonts in a
LaserWriter + (Avante Garde, Bookman, Courier, Helvetica, Narrow Hel.,
New Century Schoolbook, Palatino, Symbol, Times, Zapf Chancery, Zapf
Dingbats), took up about 1,350K on my HD. Note: I already had the bitmaps
for the fonts installed before ATM, your mileage will vary.) The amount
of memory that I had decreased by 200K. 100K is needed for ATM and a
minimum of 64K in needed for a font cache (you can set this). The font
cache holds the data for some of the scalled fonts that you have done. If
you use a font that has been previously scalled and is in the cache,
it appears instantaneous. The large the cache, the faster the scales are.
The scales themselves are very fast if you consider what it is doing.
Generating a 33 or 57 point size for example, took only a few seconds with
wonderful results. The larger the point size, the longer it will take.
I tested ATM with Word 4, MacWrite 4.6, MacDraw II 1.0, MacDraw 1.9.5,
both SuperPaint versions, and WriteNow 1.0. All worked.
ATM is a serious memory hog. 1meg users might want find that some of
their programs no longer run in so little room (about 600K). I don't know
if disabling ATM will help. However, it might be just your cup of tea since
it will do very nice results on QuickDraw printers such as dot matrix
printers, QuickDraw laser printers and the QD DeskJet.
BTW I didn't have time to check it out with my printer (Star NX-10) and
Epstart 2.5 (Epson printer driver) but I will report on that in a bit.
Hope you find this useful.
-- mjv@iris.brown.edu
"And, oh! Father Christmas, if you love me at all,
Bring me a big, red india-rubber ball."
A.A. Milne "Now We are Six"
------------------------------
Date: 6 Dec 89 03:09:43 GMT
From: rochester!rit!ultb!clf3678@louie.udel.edu (C.L. Freemesser)
Subject: SS -> DS drive upgrade
Message-ID: <1699@ultb.isc.rit.edu>
In article <22194@brunix.UUCP> mjv@iris.brown.edu (Marshall Vale) writes:
>
> I have two friends who both have SS drives and would like to upgrade to DS
>drives. One has an old SF 314 with a corner button eject and the other
>has a 520STfm.
>
>1. What is a reliable and cheap DS drive to buy as a replacement? Netters
> have mentioned a Toshiba model several times.
Toshiba is a good choice. There are others, but the Toshiba is widely
available, and as cheap as $68 or so.
>2. Are there any hardware changes that need to be made? For example, if
> it can't normally recognize media changes.
I really don't think so. The circuitry in both the external drive (the
PCB board) and in the STfm should take care of the media change problem.
If they do not, simply run a jumper between pins 2 and 28 of the drive's
34 pin card edge.
However, you might have a problem with the cables. Depending on where
the connectors on the new drive (with respect to the old one) are
located, you might have to wire up some cable extensions.
>3. What is a good price for that drive and suggested place to purchase
> from?
Pay no more than $85 or so for a Toshiba. Try to get an ND-354 or an
ND-352-A. The 352-A, if I remember correctly, only requires the +12V
line. If so, be sure to cut the +5V line coming from the circuit board.
>4. Any suggestions as to what to do with the old drive.
Use it as a doorstop? Seriously, just hold onto it. Never know when
you might need it.
> Thanks for you're kind attention.
>
> BTW, one of these SS drive persons actually has the Atari color monitor
>with disk drive built it (PS 300 or PS 3000)!
If you plan on upgrading that PS-3000, be sure that drive has PLENTY of
shielding around it. That CRT will play havoc on it.
Chris Freemesser, Rochester Institute of Technology :BITNET:%clf3678@RITVAX
||| ____________ :GEnie: C.FREEMESSER
||| /___ / (and 8-bit too!) :USENET: clf3678@rit.isc
/ | \ ______/ / : .edu
Call the A.C.O.R.N BBS (716)436-3078, 300/1200 baud :<-or my BBS
------------------------------
Date: 5 Dec 89 21:36:19 GMT
From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher)
Subject: STOS Basic
Message-ID: <1862@atari.UUCP>
david@bdt.UUCP (David Beckemeyer) writes:
| In article <CMM.0.88.628643865.larserio@kvart.uio.no> larserio@IFI.UIO.NO
(LarsErikOsterud) writes:
| >One of my friend has STOS and TOS 1.2 but we tried it on my MEGA4 with
| >TOS 1.4 - It worked OK, BUT you can't move the mouse-pointer !!!!!
| Applications generated with STOS seem to exhibit this same behavior.
This is because STOS used absolute, undocumented memory locations for
mouse position. More's the pity, because a legal way of getting at
these variables _is_ documented. A couple of other software packages
exhibited this behaviour in Rainbow TOS testing here at Atari, as well.
I believe Antic has a new version of STOS that works better with Rainbow TOS.
--
||| Ken Badertscher (ames!atari!kbad)
||| Atari R&D System Software Engine
/ | \ #include <disclaimer>
------------------------------
Date: 5 Dec 89 19:23:23 GMT
From: fox!portal!atari!apratt@apple.com (Allan Pratt)
Subject: What does the read-only bit mean?
Message-ID: <1861@atari.UUCP>
VBRANDT@DBNUAMA1.BITNET writes:
> As most of you know there is a bit in the attribute byte that indicates
>READ-ONLY status when it's set. This means that the file can't be written
>to, can't be renamed or deleted.
> BUT: I can change the time/date entry with Fgsdatim() (or whatever the
>GEMDOS function is called). Is this a bug or a feature?? Or is it necessary
>to enable the desktop to retain the time/date stamp while copying read-only
>files?
Well, here's the logic behind it: setting the read-only bit means you
can't change the DATA IN THE FILE. You can still change the file's
directory entry, which includes its date and time. This is necessary
because you must be able to change the file's attribute byte, also in
the directory. If you couldn't do that, you couldn't ever
un-write-protect the file.
Alternatively, the answer is, "Because that's how Jason Loveman
implemented it."
It's not likely to change.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
------------------------------
Date: 4 Dec 89 17:00:34 GMT
From: cs.yale.edu!fischer-michael@CS.YALE.EDU (Michael Fischer)
Subject: What Kermit/UNITERM bugs?
Message-ID: <7477@cs.yale.edu>
In article <89337.135453SML108@PSUVM.BITNET> SML108@PSUVM.BITNET writes:
>On the subject of kermits and ST's...
>
>I also use the Uniterm Kermit to transfer to and from my ST. it works fine wit
>h VAX computer systems, however weird, VERY WEIRD stuff happens with Unix sys-
>tems, both System V and 4.3bsd. It works fine transferring text files, but
>gives a potpourri of errors with binary files. This DOES NOT HAPPEN ON VAXES!
> Ther really weird bit about the erros is that if you set the maximum allowabl
>e number of erros high enough, it eventually succeeds in transferring the block
>s it has trouble with. I have no idea why this happens.....
>
>Has anyone else figured this one out...
>
>Scott Le Grand aka SML108@PSUVM.PSU.EDU
I have no trouble at all with either text transfers or binary transfers
between Uniterm Kermit on my ST and C-Kermit running on a 4.3bsd system
(a Sun Sparcstation). You do have to remember to set binary mode at
both ends for binary transmissions. I usually say "kermit -ix" to the
Unix kermit, click the "binary" box on the Uniterm menu, and use the
"get" or "put" command.
==================================================
| Michael Fischer |
| Arpanet: <fischer-michael@cs.yale.edu> |
| Bitnet: <fischer-michael@yalecs.bitnet> |
| UUCP: <fischer-michael@yale.UUCP> |
==================================================
------------------------------
Date: 5 Dec 89 08:52:46 GMT
From: mcsun!cernvax!ethz!chx400!ugun2b!ugobs!bartho@uunet.uu.net (PAUL
BARTHOLDI)
Subject: What Kermit/UNITERM bugs?
Message-ID: <467@obs.unige.ch>
In article <8912010813.AA04349@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg
Csullog) writes:
> One netter mentioned problems with UNITERM's Kermit. ...
> The ONLY Kermit I trust is UNITERM's so WHAT problems are there?
I can confirm that I do use UNITERM (2.0e) Kermit almost dayly in binary mode
with the following counterparts : Vax-vms Kermit32, Vax-vms CKermit, IBM vm-cms
Kermit, Sun unix Kermit and PC Kermit 2.32 . My Atari 1040ST is connected at
19.2 Kbps to an Ethernet pad (Bridge cs/100) with XON/XOFF protocol. The line
to the IBM goes through the vax, then through a x.25 line to a central pad that
connects me to the 3090 ... From experience, I have set the packet length to
1024 (reduced to 96 max by CKermit ...) and use the CRC for error detection.
Depending on various conditions I get no errors or a few retries, but never got
locked or with unreadable file (even a single error would be rejected by the
dearcing programs). The mean transfer rate is almost 1KB/s with the Vax (780),
while it's almost 4 times slower with the IBM due to the many intermediates
nodes, but the error rate is similar. I found the 1KB packets giving the best
throughput. A 2KB is even better, but only if the retries are very rare.
I never the less remember a discussion about a year ago (or more ?) between
Simon Poole and ? concerning binary transmission. After reading all arguments,
i was convinced that UNITERM worked the right way, although the documentation
could have been interpreted differently. The fact that I never had any
problem with the 5 different versions above confirms this 'experimentaly'
I think (not a proof !)
regards and Thanks to Simon if he reads this ! Paul
----------------------------------------------------------------
| Dr Paul Bartholdi bartho@cgeuge54.bitnet |
| Observatoire de Geneve bartho@obs.unige.ch |
| 51, chemin des Maillettes 02284682161350::bartho (psi) |
| CH-1290 Sauverny 20579::ugobs::bartho |
| Switzerland +41 22 755 39 83 (fax) |
| +41 22 755 26 11 (tel) |
| +45 419 209 obsg ch (telex) |
----------------------------------------------------------------
------------------------------
End of INFO-ATARI16 Digest V89 Issue #763
*****************************************